Self-Organizing Networks are seen today as a key enabler for automated network management in next generation mobile communication networks such as LTE and LTE-Advanced. SON areas include self-configuration, self-optimization and self-healing. The first area typically focuses on the initial configuration and auto-connectivity of newly deployed Network Elements (NEs). The second area targets the optimal operation of the network. A network enabled for self-optimization automatically adapts network parameters which should lead to improved robustness, reliability and throughput. The third area, self-healing, is responsible for fault detection and resolution caused by malfunctioning hardware or faulty software.
These three core functionalities are available through the use of so-called SON functions. Such functions are designed to work independently from each other. In order to fulfill their tasks they monitor certain Key Performance Indicators (KPIs), configuration changes and alarm occurrences in the network. After gathering the required amount of information, a SON function instance may get active (i.e., run its algorithm) in order to compute new Configuration Management (CM) parameters and enforce them on the NEs requiring reconfiguration.
These three core functionalities, however, may be implemented by SON functions 10, which are designed to work independently from each other. They comprise three major parts, illustrated in FIG. 1:
(1) a monitoring phase,
(2) an algorithm execution phase, and
(3) an action execution phase.
During the monitoring phase a SON function instance observes certain Key Performance Indicators (KPIs) and collects information about the network such as configuration changes and fault occurrences. After gathering the required amount of information, the algorithm part of a SON function instance may get triggered. Its purpose is to compute new Configuration Management (CM) parameters which will be applied during the action execution phase.
Furthermore, there are three “activity schemes” of how a SON function monitors the network.
(1) The first one is the “on demand” scheme in which the monitoring part receives an explicit triggering event, such as an alarm notification.
(2) The second one is the “timed” scheme whose primary feature is to trigger the monitoring part at certain points in time (e.g. fixed time intervals).
(3) The last scheme is “continuous” which may require the monitoring phase of a SON function to be always active and evaluate available data.
Since SON function instances may perform changes to network configuration parameters during their operation, a SON coordinator, may be required to reject the requests which would cause or engage in conflicts and allow those which would guarantee a flawless network operation. These approved configuration requests will trigger the actual configuration of their corresponding network parameters. This type of coordination is usually referred to as pre-action SON coordination and is based on rules used to anticipate and avoid known conflicts between SON function instances.
Furthermore, the coordination logic itself is split into two schemes: algorithm and action coordination. The latter one is the most obvious Way of coordinating SON functions since actions show the greatest conflict potential. Since action execution requests typically contain the new configuration parameters, the coordinator is able to compare them with the current configuration or with one made at a previous point in time. The algorithm coordination, on the other side, allows decisions to be taken before the algorithm execution is triggered, i.e. at the earliest possible point in time. Such an early information acquisition can further contribute for preventing the blocking of high priority long-running SON function instances by such having a low-priority and short computation time.
Due to the fact that SON function instances may perform changes to network configuration parameters during their operation, a SON coordinator is required to reject the requests which would cause or engage in conflicts and allow those, which would guarantee a flawless network operation. These approved requests will trigger the actual configuration of their corresponding network parameters. This type of coordination is usually referred to as pre-action SON coordination and is based on rules used to anticipate and avoid known conflicts between SON function instances.
In addition, there are at least two properties of a SON function instance which may be required for coordination: the impact time and impact area. A SON function instance should be considered by a SON coordinator during the complete time period during which it is active. This time period consist mainly of the impact time. This time period includes not only the delay required to perform measurements, run the algorithm and compute new configuration parameters, but also the time required to deploy the new configurations and the time until they become relevant for subsequently active functions.
The impact area on the other side is the spatial scope within which a SON function instance modifies configuration parameters or takes measurements. More precisely, it contains the function area (area that is directly configured), the input area (area where the measurements are taken from), the effect area (the area that contains the NES that are affected by a CM change) and the safety margin (an extension to the effect area).
The impact area provides information, allowing the detection of conflicting SON function instances. To turn a potential SON function conflict into an actual conflict, the potentially conflicting SON function instances have to have an overlapping impact area. The impact area itself is defined at design time of a SON function and is used at run time by the SON coordinator.
However, approved network configuration changes may not necessarily lead to improved performance targeted by the corresponding network functions and, even more so for the network-wide performance defined by operator specific criteria. It is caused by the fact that the SON coordinator focuses only on the conflict detection and coordination. An operator may, therefore, compensate this by adding a post-action verification mechanism to determine whether a configuration change leads to a significant change in performance. It aims at computing statistical measures on performance indicators at a relevant spatial and temporal aggregation level to assess quickly the impact of a set of (SON-induced) configuration changes. This is done independently of the semantics of those configuration changes such that also performance impacts with unknown causes can be identified. The approach can be classified as a specific type of anomaly detection.
Complementary to the coordination strategy, is a post-action SON verification mechanism. It aims at computing statistical measures on performance indicators at a relevant spatial and temporal aggregation level to assess quickly the impact of a set of (SON-induced) configuration changes. This is done independently of the semantics of those configuration changes such that also performance impacts with unknown causes can be identified. The approach can be classified as a specific type of anomaly detection.
In the following, it is distinguished between a “CM undo” and a “CM rollback” with the following definitions: a CM undo reverts all or a subset of CM parameters after they have been enforced on the corresponding Network Elements (NEs). A CM rollback on the other side is a technique implemented by the SON coordinator. The coordinator may buffer CM change request, try to detect potential conflicts between the buffered requests and NACK those preventing a flawless network operation. Thus, a CM rollback is performed before the corresponding changes are propagated to the NEs.
Approved network configuration changes may not necessarily lead to improved performance targeted by the corresponding network functions and, even more so for the network-wide performance defined by operator specific criteria. This is caused by the fact that the SON coordinator can only take into account potential conflict situation known are priori and usually does not have any knowledge on factors beyond the SON function instances, like alarms on certain cells, let alone external conditions not visible at all in the network data (e.g., a special event condition or an external interferer). An operator may therefore compensate this by adding a post-action verification mechanism to determine whether a (set of) configuration action(s) really leads to improvement or not. This mechanism may include the execution of a pre-defined verification plan and may require a training phase, needed for performance degradation detection. In addition to the detection of “degradations”, it is also relevant to verify the proper operation of the network, i.e. no change/no degradation or to provide proof of an improvement in the network performance. This applies to all terms of “degradation” in the present content.
Should an undesired network state be detected, the verification mechanism will try to diagnose it, i.e., identify the CM changes (acknowledged earlier by the SON coordinator) which caused the undesired state and take an action (e.g., reverting the changes, escalation to a human operator). This leads to a generic structure 11, as illustrated in FIG. 2.
In FIG. 2 the verification algorithm analyzes CM, PM and FM data in order to detect performance degradation. As soon as enough data is collected, the algorithm determines the affected NEs, performs a CM and FM history search and assembles a new configuration. This new configuration includes CM settings made at a previous point in time. Then, the computed CM parameters are enforced on the corresponding NEs, i.e. a CM undo has been carried out.
Consequently, a workflow may be present that resembles the one of a SON function. As shown in FIG. 3 the phase during which the required information is collected can be represented as a monitoring phase 12 of a SON function 10. Furthermore, a verification algorithm or verification procedure and a CM undo or an CM undo functionality can be represented as an algorithm execution 13 and an action execution phase 14, respectively.
However, having such a SON verification function immediately raises the question about its coordination. A SON function that is not properly coordinated may lead to configuration conflicts, undesired network behavior and performance drops. A main cause for this to happen may be that the verification algorithm is allowed to gather information at any time without consulting the SON coordinator. In the time between starting the algorithm and enforcing the computed CM changes on the NEs, SON functions may get active and be acknowledged to perform their changes. As a consequence, the verification algorithm will have an inaccurate view of the network and inappropriate decisions may be taken. This is the first problem that this invention tends to solve.
Another problem that needs to be addressed is highly connected with the fact that SON functions are intended to work independently from each other since they may be developed by different vendors. Since a SON function may not only be stateless, but also stateful, one may extend it with verification capabilities. A function may track its own CM changes and request an old configuration when necessary. In other words, a SON function following this strategy would try to verify whether its previously computed configuration leads to the desired effect and would perform the required changes otherwise.
FIG. 4 illustrates exemplary coordination principles 15. As soon as the monitoring phase 12 completes, SON function 1 and SON function 2 will ask the coordinator 16 for algorithm execution permission 17. The outcome of the algorithm execution 17 or algorithm computation may be a new or an old configuration which will be applied only if a function's action execution request is granted. This, however, leads to the problem that SON functions are not able to correctly determine if exactly their own change has led to an undesired behavior. Since SON functions do not exchange context information, they are not capable of identifying the function that has caused a problem.